I’ll be at Debconf5 by 9 AM on Sunday morning! I’m taking an early flight tomorrow morning to NYC, and have an hour or two of layover before boarding a plane to Helsinki. I’m looking forward to seeing everyone. I thought I was going to be on the same plane as Andres, Erinn, and Clint, but it turns out they are on the same flight I am, only one day before. Oh well.

Delays suck. I’m actually skipping ahead here, I’d meant to blog about updating the dak codebase into shape for whatever changes were coming up first, but it turns out I’m not in the mood for that. Besides which, most of this entry is preprepared. In the last few entries we went over the background for updating our security infrastructure to make it possible to have security team members that don’t worry about vendor-sec issues (process, overview, NIv2 aka NINJA, queue-build issues), all the while skipping fairly lightly over the question of what has to actually happen. That happens to be the way I prefer to work, lots of background tinkering, then spend as little time on actual implementation as possible; it has it’s drawbacks, but hey, I like it. Anyway, the second last step is working out in detail what’s going to happen. The delay in question was trying to get the security team to sign off on it, but unfortunately they’re busy enough that that looks like it’ll being an indefinite delay, so I’m going with the “well, ftpmaster maintains the dak/katie infrastructure for the security team, so in the end it’s our call on what’s best anyway” line of thought, and just plunging in. Fortunately the current and final plan should make pretty minimal changes to how the existing security team operate anyway, even assuming a massive testing security operation happening in parallel with them – so the downside risk is already pretty minimal. (And it was, afterall, developed in consultation with Joey, and then shopped around a few folks who’ve been doing security work for testing and kernels) What is that plan, you may well ask. It’s something like this: First, let’s restate the idea:

Concept Allow two teams to exist, the current security team as the “vendor-sec subteam”, and the full team which can expand to also include the testing-security people and others interested and able to help out with security work but who do not have access to vendor-sec.

Then, we want to think about the processes that are involved at a global level. First for uploads that can’t be made public until some later date, and can only be worked on by the “vendor-sec” enabled security team.

• Source upload to queue/unchecked (as now)
  • Upload is authenticated etc
  • Upload is moved to queue/embargoed
• Upload is autobuilt
  • Logs are sent to a procmail address
  • Logs are forwarded (by procmail) onto the vendor-sec subteam
  • Logs are signed and sent back
  • Binaries are uploaded to queue/unchecked
  • Binaries are moved to queue/embargoed
• Uploads (source + binaries) are approved from queue/embargoed by
• running amber
  • Uploads are moved into the archive
  • The archive is mirrored
• The approver issues an advisory

And likewise for issues that don’t need so much secrecy:

• Source upload to queue/unchecked-disembargo (new directory)
  • Upload is authenticated etc
  • Source+version added to unembargo table
  • Upload is moved to queue/unembargoed
• Upload is autobuilt
  • Logs are sent to a procmail address
  • Logs are forwarded (by procmail, after checking unembargo table) onto the full team
  • Logs are signed and sent back
  • Binaries are uploaded to queue/unchecked
  • Noting that the source is in the unembargo table, Binaries are moved to queue/unembargoed
• Uploads (source + binaries) are approved from queue/unembargoed by running amber
  • Uploads are moved into the archive
  • The archive is mirrored
• The approver issues an advisory

Processes are great, but they have to be supported by proper information handling, so it’s worth looking at what the above actually means for the on-disk structures, too. This is particularly important, since filesystem level security is mostly how we wall off vendor-sec stuff from other users of the system (whether they’re also working on security issues, or doing, eg, web page maintenance or something equally random). Voila:

queue/unchecked, queue/unchecked-dismebargo
    world writable
    accessible only by katie
    contents automatically cleared every 15m
queue/embargoed
    writable only by katie
    accessible by vendor-sec subteam
    amber allows packages to be ACCEPTed
    [...] allows packages to be REJECTed
queue/unembargoed
    writable only by katie
    accessible by full team
    amber allows packages to be ACCEPTed
    [...] allows packages to be REJECTed
queue/accepted
    packages only sit in accepted briefly while amber is running

And finally, to sum things up, this is what a member of the security team should expect to actually do to release an advisory:

• Upload package to queue/unchecked (or queue/unchecked-disembargo)
• Wait for build logs to be sent to your address
• Check and sign those build logs
• Check the final packages in queue/embargoed (or queue/unembargoed)
• Run amber over the packages to accept them
• Fill in the template advisory generated and send it to the -announce list

The differences between that process and the current one used by the security team is pretty minor, ttbomk: currently uploads sit in queue/accepted not queue/embargoed, and currently the security team ignore the template advisories amber generates preferring to make their own – aiui, this is mostly due to delays in actually receiving the advisory template since amber mails it instead of leaving it somewhere convenient on disk. Anyway, that’s what the plan looks like. We should see how well it survives contact with the enemy, or at least reality, remarkably soon. (Of course, I guess “political issues” could always foul it up completely anyway, particularly going by the fact that it’s been more or less the only problem raised by the folks I’ve passed this on to… Oh well, reconstruct that bridge when we get to it, I guess)

I have a picture of this space on my computer and, for the life of me, I cannot remember the name of it. If anyone can identify it, please email me. p.s., AJ, I thought we all agreed NIv2 would be named NINJA?

Joey Hess blogs about how nice Quod Libet is. In general, I agree with him. I use it at work now, though I've historically preferred cplay as it's nice and simple and does what I want. Due to the popularity of Audioscrobbler and my curiosity about it, I decided I'd try out some of the clients that support it. It was sort of a rude awakening to discover that QL won't actually work on AMD64, which I use at home. The reason for the bug not being fixed (or RC for that matter) is really sort of funny in a sad way. EDIT: Hmm, that didn't take long. The bug's now fixed (of course, not due to my whiny blogging, but rather due to Steve upgrading the bug to RC.) Something valuable to take away from this: amd64 bugs that qualify are RC and should be treated as such. I'd probably still hesitate to upgrade severities in the future without input from an RM, but at least now it's not a questionable situation. Also, yay, now I can use QL at home. Thanks for the quick fix, Joe. Thou ninja'st. :)

Joey Hess blogs about how nice Quod Libet is. In general, I agree with him. I use it at work now, though I've historically preferred cplay as it's nice and simple and does what I want. Due to the popularity of Audioscrobbler and my curiosity about it, I decided I'd try out some of the clients that support it. It was sort of a rude awakening to discover that QL won't actually work on AMD64, which I use at home. The reason for the bug not being fixed (or RC for that matter) is really sort of funny in a sad way.

So, I’ve recently switched to Mutt for mail-reading purposes, and aside from it taking a motherload of all time to get all the necessary parts setup and configured properly having never done it before, I am so far extremely happy. It looks like it’s going to be a huge timesaver overall once I have everything tweaked to my liking. Yay for Erinn giving me her super muttrc file which was incredibly helpful and neato. (Though I’m still tweaking the display colours in it: I agree, helix, I don’t like yours. :-p) All I need to do now is get my spam filtering setup in both procmail and the necessary hooks in Mutt, and add a few macros of my own. (And finish fleshing out my aliases.) Oh, and I need to fix some of my procmail rules, probably to sort by List-Id instead of ^TO, because I believe many of these lists are using bcc or something which breaks my list filtering. I haven’t looked at it too much yet. One of my friends gave me lots of digital pictures from various things: Home-brewed Halloween fun: I was traumatized that I forgot my cross at home. I also apologize for any trauma caused by this picture. (Yes, all three of us are indeed girls.) Edit: added in proper image thumbnail to not be evil.

I've become increasingly aggravated by my inability to read captchas such as this one. Am I becoming a robot or are they making it stupidly hard for humans these days? If I am becoming a robot, when do I get my hot pink exoskeleton?